REMARKS 



Claims 1-28 are pending. Claims 1-28 were rejected under 35 U.S.C. 112(2) as being 
indefinite because of use of the term "associated with." The Applicants respectfully submit that 
the term associated with is appropriate. The phrases "an encoder associated with a first network 
node" and "a encoder associated with a second network node" are believed clear. For example, 
an encoder may be as the Examiner suggests, "incorporated within" the first network node. 
However, requiring an encoder to be "incorporated within" the first network node is believed too 
narrow. In some instances, an encoder may be implemented as software running on a processor 
of the first network node, it may be a line card included in the first network node, or may be a 
box sitting alongside a first network node. The recitation "associated with" provides clear scope 
of the relationship between the encoder and the first network node. Consequently, the phrase 
"associated with" is believed clear. Applicants respectfully request that the rejection to the term 
"associated with" be withdrawn. 

Claims 4 and 6 were rejected because the Examiner argues they recite limitations already 
found in claim 1. Claims 4 and 6 have been canceled. 

Claims 1-9, 11, 14-17, and 23-26 including independent claims 1, 23, and 26 were 
rejected under 35 U.S.C. 103(a) as being unpatentable over Schuster (USP 6243846) in view of 
Kim (USPAP 2003/0226092). Independent claim 18 was rejected under 35 U.S.C. 103(a) as 
being unpatentable over Schuster (USP 6243846) in view of Kim (USPAP 2003/0226092) and 
further in view of Gibson (USP 6895019). The Examiner argues that Schuster describes all 
recitations of the independent claims 1, 23, and 26 except "amount of error correction 
information generated is based at least partially upon the amount of loss." The Examiner relies 
on Kim to teach or suggest this recitation in claims 1, 18, 23, and 26. The Applicants 
acknowledge that Kim notes that "the number of the currently transmitted parity packets is 
reduced when the channel state is good, and the number of the parity packets is increased and 
transmitted when the channel state is bad, in order to improve received image quality. 
Information on the channel state is transmitted and received using the RTCP (real-time transport 
control protocol)." 

However, even if there is sufficient motivation to combine Schuster and Kim, Schuster 
and Kim neither alone nor in combination teach or suggest "establishing a forward error 
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correction tunnel between the encoder and the decoder." Gibson also cited for independent 
claim 18, also does not teach or suggest this recitation. 

Schuster does not teach or suggest the use of tunnels to implement forward error 
correction. The Examiner argues that Schuster's RTP protocol is a tunnel protocol. The 
Applicants respectfully disagree. RTP (Real-time Transport Protocol) is a standard packet 
format for delivering audio and video data. No tunnels are established between network nodes in 
the standard Real-time Transport Protocol. Furthermore, RTP does not establish any tunnel 
between an encoder and a decoder. Still furthermore, RTP does not establish any error 
correction tunnel between the encoder and the decoder. RTP is described in detail in RFC 3550 

"This memorandum describes RTP, the real-time transport protocol. RTP provides end- 
to-end network transport functions suitable for applications transmitting real-time data, such as 
audio, video or simulation data, over multicast or unicast network services. RTP does not 
address resource reservation and does not guarantee quality-of- service for real-time services." 
(RFC 3550) 

Although RFC 3550 does not explicitly prevent tunneling using RTP, there is nothing to 
suggest that RTP as implemented in RFC 3550 uses tunneling between an encoder and a 
decoder. The Examiner suggests that RTP is run on top of TCP/IP and this creates a tunnel. 
Applicants respectfully disagree. Just because a protocol is run on top of another protocol does 
not create a tunnel. For example, TCP is run on top of IP but this does not necessarily create a 
tunnel. In fact, RTP in fact teaches away from establishing a tunneling between an encoder and 
a decoder because RTP was developed as a multicast protocol, although it can be used as a 
unicast protocol. But even used as a unicast protocol, there is no suggestion that a tunnel would 
ever be needed or desired. 

The same is true for Kim as Kim also describes using RTP. "The offsets may be included 
in the extension fields of the RTP packet header for the respective packets, and for example, 
application of this to the case of FIG. 7 results in the case of FIG. 9. In this instance, a 
transmission order from the transmitter to the receiver is defined to be the first packet PI, the 
second packet P2, the third packet P3, the fourth packet P4, the first parity packet PP1, and the 
second parity packet PP2." [52] Kim also describes using RTCP, which is described as 
essentially an augmented version of RTP. "Information on the channel state is transmitted and 
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received using the RTCP (real-time transport control protocol)." [60] RTCP is also not a 
tunneling protocol. RTCP is defined in the same RFC 3550. "The data transport is augmented 
by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to 
large multicast networks, and to provide minimal control and identification functionality." (RFC 
3550) 

Again, RFC 3550 does not explicitly preclude tunneling using RTCP. However, there is 
nothing to suggest that RTCP as implemented in RFC 3550 uses any tunneling whatsoever. In 
fact, RTP and RTCP teach away from establishing a tunneling between an encoder and a decoder 
because RTP and RTCP were originally developed as multicast protocols. 

It is possible that RTP may be run on top of protocols such as TCP/IP or UDP. However, 
even running RTP or RTCP on top of these other protocols is not establishing a forward error 
correction tunnel between an encoder and a decoder. 

USPN 6,079,042 ("Vaman"), USPN 6,895,019 ("Gibson"), and USPN 5,642,365 
("Murakami") also cited by the Examiner similarly do not "allow configuration based on the 
amount of loss between two particular network nodes" as variably recited in the independent 
claims. Vaman, Gibson, Murakami, and Schuster are all believed to merely mention network 
based error correction schemes, without determining the amount of loss between two specific 
nodes. 

In light of the above remarks and claim amendments, the Applicants believe that all 
pending claims are allowable in their present form. Please feel free to contact the undersigned at 
the number provided below if there are any questions, concerns, or remaining issues. 

Respectfully submitted, 
BEYER WEAVER LLP 

/Godfrey Audrey Kwan/ 
Godfrey Audrey Kwan 
Registration No. 46,850 

P.O. Box 70250 
Oakland, CA 94612-0250 
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